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BRIEF OF APPELLANT 

This Appeal Brief, pursuant to the Notice of Appeal filed April 21, 2009, is an appeal 
from the rejection of the Examiner in the Final Office Action dated January 21, 2009. 


REAL PARTY IN INTEREST 

International Business Machines, Inc. is the real party in interest. 


RELATED APPEALS AND INTERFERENCES 

None. 

STATUS OF CLAIMS 

Claims 1 and 20-33 are rejected. Claims 2-19 are cancelled. This Brief is in support of 
an appeal from the rejection of claims 1 and 20-33. 


STATUS OF AMENDMENTS 

An after-final amendment filed 03/18/2009 was entered as indicated in the Advisory 
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Action as mailed 03/30/2009. 


SUMMARY OF CLAIMED SUBJECT MATTER 

CLAIM 1 - INDEPENDENT 

The present invention provides a computer implemented method for generating a goods 
receipt (410, FIG. 1) for approving and paying an invoice (89, FIG. 1) for commodities triggered 
by a three way match whereby said invoice must match terms and conditions of a purchase order 
(87, FIG. 1), and goods received must match those stated in quality and quantity against said 
purchase order (specification, page 4, lines 13-15; page 6, line 17 - page 7, line 11; page 9, lines 
9-11; page 16, lines 16-21; page 5, lines 2-5). 

A front end server (40, FIG. 1) receives, from a requestor (46, FIG. 1), a purchase request 
(51, FIG. 1) for goods (specification, page 8, lines 9-15; page 9, lines 1-2). 

The goods have a designation denoting that the goods are receivable, which requires a 
positive confirmation from the requestor to provide authorization to pay for the goods 
(specification, page 8, lines 17-18; page 13, lines 6-9). 

The designation is stored in the front end server (specification, page 8, line 19). 

An invoice processing system (FIG. 2) comprises the front end server, an application 
server (423, FIG. 2) and a back end server (42, FIGS. 1 and 2), wherein the back end server is 
coupled to the front end server via the application server, wherein the front end server comprises 
a positive confirmation application (424, FIG. 2) and a database (425, FIG. 2), and wherein the 
application server comprises a positive confirmation bridge (426, FIG. 2) and (FIG. 2 and 
specification, page 8, lines 9-12). 

The front end server sends, to the back end server, a requisition comprising requirements 
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relating to the received purchase request and including the designation (FIG. 1 and specification, 
page 9, lines 1-3). 

The back end server generates, in response to receiving the requisition sent by the front 
end server, the purchase order (87, FIG. 1) based on the requisition (FIG. 1 and specification, 
page 9, line 4). 

The back end server transmits or delivers the purchase order to a vendor (48, FIG. 1) that 
can provide the requested goods (FIG. 1 and specification, page 9, lines 4-6). 

After the purchase order to the vendor has been transmitted or delivered, the application 
server receives an invoice (89, FIG. 1) from the vendor, wherein the invoice references the 
purchase order and requests payment for the goods (FIG. 1 and specification, page 9, lines 9-1 1). 

After the application server receives the invoice from the vendor, the positive 
confirmation bridge marks the invoice to indicate that the positive confirmation (421, FIG. 2) is 
required (FIG. 2 and specification, page 11, lines 7-9). 

After the positive confirmation bridge has marked the invoice, the back end server 
receives the invoice from the application server (FIG. 2 and specification, page 9, lines 9-11); 

Responsive to the back end server receiving the invoice from the positive confirmation 
bridge, the back end server communicates transaction information pertaining to the invoice to 
the front end server (FIGS. 1-2 and specification, page 9, lines 12-16). 

After the transaction information is communicated, the positive confirmation application 
provides notice to the requestor that the invoice has been received and that the invoice includes 
the required positive confirmation (FIG. 2 and specification, page 1 1, lines 10-11; page 12, lines 
7-9). 

After notice to the requestor has been provided, the front end server receives a response 
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from the requestor (406 and 408, FIG. 2) for authorizing or rejecting payment for the goods 
(FIG. 2 and specification, page 11, line 17 - page 12, line 3; page 9, lines 17-18). 

If the received response is for authorizing payment, then an automated receipt transaction 
file, which includes goods receipt (410, FIG. 1), is created, and the transaction file is entered into 
an enterprise resource planning system for payment (specification, page 9, lines 19-22; page 12, 
lines 16-20; page 14, lines 13 - page 15, line 4). 

If the received response is for rejecting payment, then an e-mail notification to an 
accounts payable system is created for returning said invoice to the vendor (specification, page 
9, line 22 -page 10, line 4). 

CLAIM 20 - DEPENDENT 

The present invention provides the method of claim 1, wherein the method further 
comprises: after the front end server receives the response, the front end server records the 
response in the database (specification, page 12, lines 4-6). 

CLAIM 21 - DEPENDENT 

The present invention provides the method of claim 1, wherein the received response is 
for authorizing payment for the goods (specification, page 9, lines 19-22). 

CLAIM 22 - DEPENDENT 

The present invention provides the method of claim 21, wherein the application server 
(423, FIG.2) further comprises a requisition bridge (427, FIG. 2), wherein the method further 
comprises: after the response is received, the application server notifies the back end server via 
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the requisition bridge that payment for the goods has been authorized (specification, page 1 1 , 
lines 4-5). 


CLAIM 23 - DEPENDENT 

The present invention provides the method of claim 1, wherein the received response is 
for rejecting payment for the goods (specification, page 9, lines 22 - page 10, line 4). 

CLAIM 24 - DEPENDENT 

The present invention provides the method of claim 1, wherein the notice directs the 
requestor to a location where the positive confirmation can be performed (specification, page 11, 
lines 11-13). 

CLAIM 25 - DEPENDENT 

The present invention provides the method of claim 1, wherein the application server 
further comprises a confirmation interface to the database, wherein the confirmation interface is 
configured to be executed by the positive confirmation application (424, FIG. 2), and wherein 
the method further comprises after said providing notice and before said receiving the response: 
providing the confirmation interface to the requester to enable the requestor to both enter an 
identifier of the invoice and obtain access to data comprised by the invoice (specification, page 
11, lines 17-20). 


CLAIM 26 - DEPENDENT 

The present invention provides the method of claim 25, wherein said receiving the 
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response is performed via the confirmation interface ( specification, page 1 1, line 17 - page 12, 
line 3). 


CLAIM 27 - INDEPENDENT 

The present invention provides a computer implemented method for processing a 
purchase request for goods or services (specification, page 4, lines 13-15; page 6, line 17 - page 
7, line 11; page 9, lines 9-11; page 16, lines 16-21; page 5, lines 2-5). 

A front end server (40, FIG. 1) receives, from a requestor (46, FIG. 1), a purchase request 
(51, FIG. 1) for goods or services (specification, page 8, lines 9-15; page 9, lines 1-2). 

The goods or services have a designation denoting that the goods are receivable, which 
requires a positive confirmation from the requestor to provide authorization to pay for the goods 
or services (specification, page 8, lines 17-18; page 13, lines 6-9). 

The designation is stored in the front end server (specification, page 8, line 19). 

An invoice processing system (FIG. 2) comprises the front end server, an application 
server (423, FIG. 2) and a back end server (42, FIGS. 1 and 2), wherein the back end server is 
coupled to the front end server via the application server, wherein the front end server comprises 
a positive confirmation application (424, FIG. 2) and a database (425, FIG. 2), and wherein the 
application server comprises a positive confirmation bridge (426, FIG. 2) and (FIG. 2 and 
specification, page 8, lines 9-12). 

The front end server sends, to the back end server, a requisition comprising requirements 
relating to the received purchase request and including the designation (FIG. 1 and specification, 
page 9, lines 1-3). 

The back end server generates, in response to receiving the requisition sent by the front 
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end server, the purchase order (87, FIG. 1) based on the requisition (FIG. 1 and specification, 
page 9, line 4). 

The back end server transmits or delivers the purchase order to a vendor (48, FIG. 1) that 
can provide the requested goods or services (FIG. 1 and specification, page 9, lines 4-6). 

After the purchase order to the vendor has been transmitted or delivered, the application 
server receives an invoice (89, FIG. 1) from the vendor, wherein the invoice references the 
purchase order and requests payment for the goods (FIG. 1 and specification, page 9, lines 9-1 1). 

After the application server receives the invoice from the vendor, the positive 
confirmation bridge marks the invoice to indicate that the positive confirmation (421, FIG. 2) is 
required (FIG. 2 and specification, page 11, lines 7-9). 

After the positive confirmation bridge has marked the invoice, the back end server 
receives the invoice from the application server (FIG. 2 and specification, page 9, lines 9-1 1); 

Responsive to the back end server receiving the invoice from the positive confirmation 
bridge, the back end server communicates transaction information pertaining to the invoice to 
the front end server (FIGS. 1-2 and specification, page 9, lines 12-16). 

After the transaction information is communicated, the positive confirmation application 
provides notice to the requestor that the invoice has been received and that the invoice includes 
the required positive confirmation (FIG. 2 and specification, page 11, lines 10-11; page 12, lines 
7-9). 

The notice directs the requestor to a location where the positive confirmation can be 
performed (specification, page 11, lines 11-13). 

After notice to the requestor has been provided, the front end server receives a response 
from the requestor (406 and 408, FIG. 2) for authorizing or rejecting payment for the goods or 
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services (FIG. 2 and specification, page 11, line 17 - page 12, line 3; page 9, lines 17-18). 

After the front end server receives the response, the front end server records the response 
in the database (specification, page 12, lines 4-6). 

CLAIM 28 - DEPENDENT 

The present invention provides the method of claim 27, wherein the received response is 
for authorizing payment for the goods (specification, page 9, lines 19-22). 

CLAIM 29 - DEPENDENT 

The present invention provides the method of claim 28, wherein the application server 
(423, FIG.2) further comprises a requisition bridge (427, FIG. 2), wherein the method further 
comprises: after the response is received, the application server notifies the back end server via 
the requisition bridge that payment for the goods has been authorized (specification, page 11, 
lines 4-5). 

CLAIM 30 - DEPENDENT 

The present invention provides the method of claim 27, wherein the received response is 
for rejecting payment for the goods (specification, page 9, lines 22 - page 10, line 4). 

CLAIM 3 1 - DEPENDENT 

The present invention provides the method of claim 27, wherein the notice directs the 
requestor to a location where the positive confirmation can be performed (specification, page 11, 
lines 11-13). 
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CLAIM 32 - DEPENDENT 

The present invention provides the method of claim 27, wherein the application server 
further comprises a confirmation interface to the database, wherein the confirmation interface is 
configured to be executed by the positive confirmation application (424, FIG. 2), and wherein 
the method further comprises after said providing notice and before said receiving the response: 
providing the confirmation interface to the requester to enable the requestor to both enter an 
identifier of the invoice and obtain access to data comprised by the invoice (specification, page 
11, lines 17-20). 


CLAIM 33 - DEPENDENT 

The present invention provides the method of claim 32, wherein said receiving the 
response is performed via the confirmation interface ( specification, page 11, line 17 - page 12, 
line 3). 
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GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 


1. Claims 1, 20, 21, 23-28 and 30-33 stand rejected under 35 U.S.C. § 103(a) as allegedly being 
unpatentable over US 6,507,826 Maners in view of University of New Hampshire Financial and 
Administrative Procedures, 

(http://wwXmadrnm.imli.edu/pol jproc/chapter_23/pro23J)51.htrnl; Issued by Computing and 
Information Services; Issued Date: 01/01/94; retrieved date 9/1 1/06) hereinafter, Procedures in 
further view of Furphy et al. (hereinafter Furphy, US Patent No. 6,882,983). 

2. Claims 22 and 29 stand rejected under 35 U.S.C. § 103(a) as allegedly being unpatentable 
over Maners, Procedures, and Furphy as applied to claim 21 above, and further in view of 
Gershenfeld, (Gershenfeld, Nancy. "Client-server: What Is It and Are We There Yet?" Online. 
Medford: Mar. 1995. Vol. 19, Iss. 2; pg. 60, 5 pages). 
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ARGUMENT 

GROUND OF REJECTION 1 

Claims 1, 20, 21, 23-28 and 30-33 stand rejected under 35 U.S.C. § 103(a) as allegedly 
being unpatentable over US 6,507,826 Maners in view of University of New Hampshire 
Financial and Administrative Procedures, 

(http://wvvw.fmadmdn^ Issued by Computing and 

Information Services; Issued Date: 01/01/94; retrieved date 9/1 1/06) hereinafter, Procedures in 
further view of Furphy et al. (hereinafter Furphy, US Patent No. 6,882,983). 

Claim 1 

Appellants respectfully contend that claim 1 is not unpatentable over Maners in view of 
Procedures in further view of Furphy, because Maners in view of Procedures in further view of 
Furphy does not teach or suggest each and every feature of claim 1 . 

Claim 1 recites three servers (front end server, application server, back end server). 
Noting that Manners, FIG. 2 is relevant for comparison with the preceding three servers recited 
in claim 1, Appellants note that the Examiner has not specifically identified three servers in 
Manners, FIG. 2 that allegedly corresponds to the three servers recited in claim 1, which makes 
it difficult to comprehend and assess the Examiner's argument articulated in the final office 
action mailed January 21 , 2009. 

Appellants next applies Maners to claim 1 based on either Table 1 or Table 2 infra, 
which associates the three claimed servers in claim 1 with corresponding servers in Manners, 
FIG. 2, which Appellants consider to be reasonable representations in Maners of the three 
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claimed servers (front end server, application server, back end server) in claim 1 . This is 
Appellants' best attempt to mitigate the Examiner's non-disclosure of servers in Maners that 
allegedly represent the three claimed servers in claim 1. 


Table 1 


Claimed Server 

Represented in Maners, FIG. 2 By 

front end server 

computer system 206 

application server 

MicroEDI Server 202 (or application 220 within server 202) 

back end server 

computer system 210 

Table 2 

Claimed Entity 

Represented in Maners, FIG. 2 By 

front end server 

computer system 210 

application server 

MicroEDI Server 202 (or application 220 within server 202) 

back end server 

computer system 206 


Appellants next demonstrate that the server representations in Table 1 and Table 2 do not 
satisfy various features of claim 1 alleged by the Examiner to be disclosed by Maners. 

A first reason why claim 1 is not unpatentable over Maners in view of Procedures in 
further view of Furphy in light of Tables 1 and 2 is that Maners does not disclose the feature: 
"receiving, by a front end server from a requestor, a purchase request sending, by the front 
end server to the back end server, a requisition comprising requirements relating to the received 
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purchase request generating, by the back end server in response to receiving the requisition 
sent by the front end server, said purchase order based on the requisition". 

The preceding feature of claim 1 requires that the back end server generate the purchase 
order based on a requisition received by the back end server from the front end server, wherein 
the requisition comprises requirements relating to a purchase request received by the front end 
server from the requestor. 

In consideration of Table 1, Maners does not disclose that the computer system 210 (i.e., 
the back end server in Table 1) generates the purchase order based on a requisition received by 
the computer system 210 from the computer system 206 (i.e., the front end server in Table 1), 
wherein the requisition comprises requirements relating to a purchase request received by the 
computer system 206 from a requestor. 

In fact, Maners does not disclose that the computer system 210 generates the purchase 
request. Furthermore, Maners, col. 4, lines 1-2 discloses that the computer system 210 is at the 
vendor site and thus would fulfill a purchase order rather than generate a purchase order. 
Moreover, Maners does not disclose anywhere who generates the purchase order and most 
certainly does not disclose that the computer system 210 generates the purchase order. 

Even if Maners does disclose that the computer system 210 generates the purchase order 
(which Maners does not do), Maners does not disclose that the purchase order is generated based 
on a requisition received by the computer system 210 from the computer system 206, wherein 
the requisition comprises requirements relating to a purchase request received by the computer 
system 206 from the requestor. 

Moreover, Maners does not disclose who the requestor is and thus Maners does not 
S/N: 09/819,462 13 


disclose that the purchase request is received by the computer system 206 from the requestor. 

In consideration of Table 2, Maners does not disclose that the computer system 206 (i.e., 
the back end server in Table 2) generates the purchase order based on a requisition received by 
the computer system 206 from the computer system 210 (i.e., the front end server in Table 2) , 
wherein the requisition comprises requirements relating to a purchase request received by the 
computer system 210 from the requestor. 

In fact, Maners does not disclose that the computer system 206 generates the purchase 
request. Although Maners, col. 5, lines 44-46 discloses that the computer system 206 issues out 
the purchase order, Maners does not disclose that computer system 206 generates the purchase 
order. Moreover, Maners does not disclose anywhere who generates the purchase order and 
most certainly does not disclose that the computer system 206 generates the purchase order. 

Even if Maners does disclose that the computer system 206 generates the purchase order 
(which Maners does not do), Maners does not disclose that the purchase order is generated based 
on a requisition received by the computer system 206 from the computer system 210, wherein 
the requisition comprises requirements relating to a purchase request received by the computer 
system 210 from the requestor. 

Therefore, Maners in view of Procedures in further view of Furphy does not disclose the 
preceding feature of claim 1. 

A second reason why claim 1 is not unpatentable over Maners in view of Procedures in 
further view of Furphy is that Maners does not disclose the feature: "said goods having a 
designation denoting that the goods are receivable which requires a positive confirmation from 
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the requestor to provide authorization to pay for the goods". 

Appellants assert that the preceding feature of claim 1 requires that the requestor 
provides positive confirmation to provide authorization to pay for the goods. However, Maners 
does not disclose who the requestor is and thus does not disclose that the requestor provides 
positive confirmation to provide authorization to pay for the goods. 

In fact, Maners discloses that the MicroEDI Server 202 provides positive confirmation to 
provide authorization to pay for the goods. See Maners, col. 6, lines 52-55 ("When an invoice is 
in "posted" status, the invoice has been processed by the MicroEDI Server 202 and determined 
valid and submitted to the company accounts payable computer system 206 for payment 
processing"). However, Maners does not disclose that the MicroEDI Server 202 is the requestor. 

Therefore, Maners in view of Procedures in further view of Furphy does not disclose the 
preceding feature of claim 1 . 

A third reason why claim 1 is not unpatentable over Maners in view of Procedures in 
further view of Furphy in light of Tables 1 and 2 is that Maners does not disclose the feature: 
"said goods having a designation denoting that the goods are receivable which requires a 
positive confirmation from the requestor to provide authorization to pay for the goods said 
designation being stored in the front end server. 

Appellants assert that Maners does not disclose that a designation denoting that the goods 
require the positive confirmation are stored in the front end server (i.e., stored either in the 
computer system 206 (Table 1) or in the computer system 210 (Table 2)). In fact, Appellants 
assert that Maners does even disclose the existence of a designation denoting that the goods 
require the positive corifirmation to provide authorization to pay for the goods. 
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However, even if it is argued that the "posted" status for an invoice, as disclosed in 
Maners, col. 6, lines 52-55 is the designation denoting that the goods require the positive 
confirmation (which Appellants do not agree with), Appellants assert that Maners, col. 6, lines 
34-38 discloses that the MicroEDI Server 202 comprises an invoice history table (e.g., the table 
shown in Maners, FIG. 4) and that Maners, col. 6, lines 52-55 discloses that an invoice having 
the "posted" status is stored in the invoice history table in the MicroEDI Server 202, and not in 
the computer system 206 or in the computer system 210. 

Therefore, Maners in view of Procedures in further view of Furphy does not disclose the 
preceding feature of claim 1. 

A fourth reason why claim 1 is not unpatentable over Maners in view of Procedures in 
further view ofFurphy in light of Tables 1 and 2 is that Maners does not disclose the feature: 
"said application server comprising a positive confirmation bridge; ... said positive corifirmation 
bridge marking the invoice to indicate that said positive confirmation is required. 

In Table 1 and Table 2, the application server is the MicroEDI Server 202 (or application 
220), and Maners does not disclose that the MicroEDI Server 202 (or application 220) comprises 
a positive confirmation bridge that marks the invoice to indicate that said positive confirmation 
is required. Instead, the MicroEDI Server 202 marks the invoice listed in the table shown in 
Maners, FIG. 4 "as having "posted" status denoting that the invoice is valid and does not denote 
that the positive confirmation is required. (See Maners, col. 6, lines 52-55). 

Therefore, Maners in view of Procedures in further view of Furphy does not disclose the 
preceding feature of claim 1. 
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A fifth reason why claim 1 is not unpatentable over Maners in view of Procedures in 
further view of Furphy in light of Tables 1 and 2 is that Maners does not disclose the feature: "a 
positive confirmation from the requestor to provide authorization to pay for the goods, ... said 
front end server comprising a positive confirmation application said positive confirmation 
application providing notice to the requestor that the invoice has been received and that the 
invoice includes the required positive confirmation". 

Appellants assert that Maners does not disclose that a positive confirmation application 
in the front end server (i.e., in the computer system 206 (Table 1) or in the computer system 210 
(Table 2)) providing notice to the requestor that the invoice has been received and that the 
invoice includes the required positive confirmation of authorization to pay for the goods. 

Moreover, Maners does not even identify the requestor and thus does not disclose 
providing notice to the requestor that the invoice has been received and that the invoice includes 
the required positive confirmation of authorization to pay for the goods. 

Therefore, Maners in view of Procedures in further view of Furphy does not disclose the 
preceding feature of claim 1 . 

A sixth reason why claim 1 is not unpatentable over Maners in view of Procedures in 
further view of Furphy in light of Tables 1 and 2 is that Maners does not disclose the feature: 
"said front end server receiving a response from the requestor for authorizing or rejecting 
payment for the goods". 

Appellants assert that Maners does not disclose that the front end server (i.e., the 
computer system 206 (Table 1) or the computer system 210 (Table 2)) receives a response from 
the requestor for authorizing or rejecting payment for the goods. 
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In fact, Maners discloses that the MicroEDI Server 202 (and not the requestor) authorizes 
or rejects payment for the goods. See Maners, col. 6, lines 34-36 ("the MicroEDI Server 202 
authenticates the vendor ED number and password and determines that a user is authorized") and 
Maners, col. 6, lines 52-55 ("the invoice has been processed by the MicroEDI Server 202 and 
determined valid and submitted to the company accounts payable computer system 206 for 
payment processing"). 

Moreover, Maners does not even identify the requestor and thus does not disclose that the 
requestor authorizes or rejects payment for the goods. 

Therefore, Maners in view of Procedures in further view of Furphy does not disclose the 
preceding feature of claim 1 . 

Based on the preceding arguments, Appellants respectfully maintain that claim 1 is not 
unpatentable over Maners in view of Procedures in further view of Furphy, and that claim 1 is in 
condition for allowance. 

Claim 20 

Since claim 20 depends from claim 1, which Appellants have argued supra to not be 
unpatentable over Maners in view of Procedures in further view of Furphy under 35 U.S.C. 
§ 103(a), Appellants maintain that claim 20 is likewise not unpatentable over Maners in view of 
Procedures in further view of Furphy under 35 U.S.C. §103(a). 

In addition with respect to claim 20, Maners in view of Procedures in further view of 
Furphy does not disclose the feature: "a response from the requestor for authorizing or rejecting 
payment for the goods; ... after said front end server receiving the response, said front end server 
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recording the response in the database". 

The Examiner argues that the preceding feature of claim 20 is disclosed in Maners, col. 
5, lines 47-49 and col. 6, lines 59-60. 

In response, Appellants cite Maners, col. 5, lines 47-49 which recites: "In this case, the 
invoice information received from a vendor computer system is validated in real-time before 
acceptance for posting in the company's accounting computer system." Appellants assert that 
the preceding quote from Maners, col. 5, lines 47-49 discloses posting invoice information in the 
company's accounting computer system. In contrast, the preceding feature of claim 20 recites 
recording a response for authorizing or rejecting payment for the goods, which does not read on 
posting invoice information. Therefore, Maners, col. 5, lines 47-49 does not disclose the 
preceding feature of claim 20. 

In response, Appellants cite Maners, col. 6, lines 59-60 which recites: "An invoice that 
has been assigned a "refused" status has been rejected for payment", which does not disclose 
storing data of any kind and is therefore irrelevant to the preceding feature of claim 20. 

Accordingly, claim 20 is not unpatentable over Maners in view of Procedures in further 
view of Furphy. 

Claim 21 

Since claim 21 depends from claim 1, which Appellants have argued supra to not be 
unpatentable over Maners in view of Procedures in further view of Furphy under 35 U.S. C. 
§103 (a), Appellants maintain that claim 21 is likewise not unpatentable over Maners in view of 
Procedures in further view of Furphy under 35 U.S.C. §103(a). 

In addition with respect to claim 21, Maners in view of Procedures in further view of 
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Furphy does not disclose the feature: "wherein the received response is for authorizing payment 
for the goods". 

The Examiner argues that the preceding feature of claim 21 is disclosed in Maners, col. 
5, lines 47-49 and col. 6, lines 59-60. 

In response, Appellants cite Maners, col. 5, lines 47-49 which recites: "In this case, the 
invoice information received from a vendor computer system is validated in real-time before 
acceptance for posting in the company's accounting computer system." Appellants assert that 
the preceding quote from Maners, col. 5, lines 47-49 related to invoice information and not to a 
response for authorizing payment for the goods. Therefore, Maners, col. 5, lines 47-49 does not 
disclose the preceding feature of claim 21 . 

In response, Appellants cite Maners, col. 6, lines 59-60 which recites: "An invoice that 
has been assigned a "refused" status has been rejected for payment", which does not disclose 
storing anything relating to a response for authorizing payment for the goods and is therefore 
irrelevant to the preceding feature of claim 21 . 

Accordingly, claim 21 is not unpatentable over Maners in view of Procedures in further 
view of Furphy. 

Claim 23 

Since claim 23 depends from claim 1, which Appellants have argued supra to not be 
unpatentable over Maners in view of Procedures in further view of Furphy under 35 U.S.C. 
§103 (a), Appellants maintain that claim 23 is likewise not unpatentable over Maners in view of 
Procedures in further view of Furphy under 35 U.S.C. §103(a). 
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Claim 24 

Since claim 24 depends from claim 1 , which Appellants have argued supra to not be 
unpatentable over Maners in view of Procedures in further view of Furphy under 35 U.S.C. 
§ 103(a), Appellants maintain that claim 24 is likewise not unpatentable over Maners in view of 
Procedures in further view of Furphy under 35 U.S.C. § 103(a). 

In addition with respect to claim 24, Maners in view of Procedures in further view of 
Furphy does not disclose the feature: "wherein the notice directs the requestor to a location 
where the positive confirmation can be performed" (emphasis added. 

The Examiner argues: "Maners discloses providing notice to the requestor to a location 
where positive confirmation can be performed. "And an invoice that is assigned an "operational 
hold' status is being held for validation and posting until certain information and/or authorization 
can be obtained by the Micro EDI server 202. Typically, an operational hold' status for an 
invoice requires additional information or authorization be entered into the MicroEDl Server 202 
by company personnel." Col. 6 lines 60-67; and notification of authorization agent in col. 9, also 
col. 11 claims 5,8." 

In response, Appellants assert that the Examiner's quote and discussion of Maners, col. 6, 
lines 60-67 discloses that an operational hold' status for an invoice requires additional 
information or authorization be entered into the MicroEDl Server 202 by company personnel, 
which does not disclose that the notice directs the requestor to a location where the positive 
confirmation can be performed as claimed. 

In further response, Appellants assert that the Examiner's citation of Maners, col. 6, lines 
60-67 discloses in Maners, col. 9, lines 5-8 "to notify the authorizing agent for the company, 
such as at a computer system 224, that a particular orphan invoice requires a release 
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authorization", which does not disclose that the notice directs the requestor to a location where 
the positive confirmation can be performed as claimed. 

In further response, Appellants assert that the Examiner's citation of Maners, col. 11, 
claim 5 recites "wherein the invoice information includes an authorizing agent and wherein the 
invoice processing server is further operable to notify the authorizing agent to determine if the 
invoice is authorized for processing", which does not disclose that the notice directs the 
requestor to a location where the positive confirmation can be performed as claimed. 

In further response, Appellants assert that the Examiner's citation of Maners, col. 11, 
claim 8 recites "sending a message to an authorizing agent requesting payment authorization to 
validate the invoice information", which does not disclose that the notice directs the requestor to 
a location where the positive confirmation can be performed as claimed. 

Accordingly, claim 24 is not unpatentable over Maners in view of Procedures in further 
view of Furphy. 

Claim 25 

Since claim 25 depends from claim 1, which Appellants have argued supra to not be 
unpatentable over Maners in view of Procedures in further view of Furphy under 35 U.S. C. 
§103 (a), Appellants maintain that claim 25 is likewise not unpatentable over Maners in view of 
Procedures in further view of Furphy under 35 U.S.C. §103(a). 

In addition with respect to claim 25, Maners in view of Procedures in further view of 
Furphy does not disclose the feature: "wherein the application server further comprises a 
confirmation interface to the database, wherein the confirmation interface is configured to be 
executed by the positive confirmation application, and wherein the method further comprises 
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after said providing notice and before said receiving the response: providing the confirmation 
interface to the requester to enable the requestor to both enter an identifier of the invoice and 
obtain access to data comprised by the invoice". 

The Examiner argues: "Maners do not specifically disclose wherein the application 
server further comprises a confirmation interface to the database, Furphy however teaches a 
communication interface provided to both the buying and selling companies to resolve 
discrepancies between the purchase order data and the invoice data. Col. 4 lines 32-35; col. 5 
lines 20-28; col. 8 lines 33-41 response via interface." 

In response, Appellants assert that the Examiner's allegation in Furphy of a 
"communication interface provided to both the buying and selling companies to resolve 
discrepancies between the purchase order data and the invoice data" does not read on "the 
confirmation interface ... to enable the requestor to both enter an identifier of the invoice and 
obtain access to data comprised by the invoice" as claimed. 

Accordingly, claim 25 is not unpatentable over Maners in view of Procedures in further 
view of Furphy. 

Claim 26 

Since claim 26 depends from claim 1, which Appellants have argued supra to not be 
unpatentable over Maners in view of Procedures in further view of Furphy under 35 U.S.C. 
§103 (a), Appellants maintain that claim 26 is likewise not unpatentable over Maners in view of 
Procedures in further view of Furphy under 35 U.S.C. §103(a). 


Claim 27 
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As to claim 27, the Examiner argues: "Claim 27 has similar limitations found in claims 1 
and 20 in combination, and therefore is rejected by the same art and rationale." 

In response, Appellants note that the Examiner has not even addressed the following 
feature of claim 27 which does not appear in claim 1 : "said notice directing the requestor to a 
location where the positive confirmation can be performed". 

In further response, Appellants note that the Examiner has not even addressed the 
following feature of claim 27 which does not appear in claim 1 : "after said front end server 
receiving the response, said front end server recording the response in the database". 

Appellants assert that Maners in view of Procedures in further view of Furphy does not 
disclose te preceding two features of claim 27, as discussed infra, in conjunction with a seventh 
reason and an eighth reason why claim 27 is not unpatentable over Maners in view of Procedures 
in further view of Furphy. 

By failing to state any argument to demonstrate that Maners in view of Procedures in 
further view of Furphy allegedly discloses the preceding two features of claim 27, and even 
failing to acknowledge and address the very existence of the two preceding two features in claim 
27, the Examiner has failed to establish a prima facie case in relation to claim 27. Accordingly, 
Appellants assert that the rejection of claim 27 under 35 U.S.C. § 103(a) should be reversed 
irrespective of whether or not Maners in view of Procedures in further view of Furphy fails 
disclose any other features of claim 27. 

Appellants next present additional arguments in traverse of the rejection of claim 27. 

Appellants respectfully contend that claim 27 is not unpatentable over Maners in view of 
Procedures in further view of Furphy, because Maners in view of Procedures in further view of 
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Furphy does not teach or suggest each and every feature of claim 27. 

Claim 27 recites three servers (front end server, application server, back end server). 
Noting that Manners, FIG. 2 is relevant for comparison with the preceding three servers recited 
in claim 27, Appellants note that the Examiner has not specifically identified three servers in 
Manners, FIG. 2 that allegedly corresponds to the three servers recited in claim 27, which makes 
it difficult to comprehend and assess the Examiner's argument articulated in the final office 
action mailed January 21, 2009. 

Appellants next applies Maners to claim 27 based on either Table 1 or Table 2, (see 
discussion supra of claim 1 for Table 1 and Table 2) which associates the three claimed servers 
in claim 27 with corresponding servers in Manners, FIG. 2, which Appellants consider to be 
reasonable representations in Maners of the three claimed servers (front end server, application 
server, back end server) in claim 27. This is Appellants' best attempt to mitigate the Examiner's 
non-disclosure of servers in Maners that allegedly represent the three claimed servers in claim 
27. 

Appellants next demonstrate that the server representations in Table 1 and Table 2 do not 
satisfy various features of claim 27 alleged by the Examiner to be disclosed by Maners. 

A first reason why claim 27 is not unpatentable over Maners in view of Procedures in 
further view of Furphy in light of Tables 1 and 2 is that Maners does not disclose the feature: 
"receiving, by a front end server from a requestor, a purchase request ...; sending, by the front 
end server to the back end server, a requisition comprising requirements relating to the received 
purchase request generating, by the back end server in response to receiving the requisition 
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sent by the front end server, said purchase order based on the requisition". 

The preceding feature of claim 27 requires that the back end server generate the purchase 
order based on a requisition received by the back end server from the front end server, wherein 
the requisition comprises requirements relating to a purchase request received by the front end 
server from the requestor. 

In consideration of Table 1, Maners does not disclose that the computer system 210 (i.e., 
the back end server in Table 1) generates the purchase order based on a requisition received by 
the computer system 210 from the computer system 206 (i.e., the front end server in Table 1), 
wherein the requisition comprises requirements relating to a purchase request received by the 
computer system 206 from a requestor. 

In fact, Maners does not disclose that the computer system 210 generates the purchase 
request. Furthermore, Maners, col. 4, lines 1-2 discloses that the computer system 210 is at the 
vendor site and thus would fulfill a purchase order rather than generate a purchase order. 
Moreover, Maners does not disclose anywhere who generates the purchase order and most 
certainly does not disclose that the computer system 210 generates the purchase order. 

Even if Maners does disclose that the computer system 210 generates the purchase order 
(which Maners does not do), Maners does not disclose that the purchase order is generated based 
on a requisition received by the computer system 210 from the computer system 206, wherein 
the requisition comprises requirements relating to a purchase request received by the computer 
system 206 from the requestor. 

Moreover, Maners does not disclose who the requestor is and thus Maners does not 
disclose that the purchase request is received by the computer system 206 from the requestor. 
S/N: 09/819,462 26 


In consideration of Table 2, Maners does not disclose that the computer system 206 (i.e., 
the back end server in Table 2) generates the purchase order based on a requisition received by 
the computer system 206 from the computer system 210 (i.e., the front end server in Table 2) , 
wherein the requisition comprises requirements relating to a purchase request received by the 
computer system 210 from the requestor. 

In fact, Maners does not disclose that the computer system 206 generates the purchase 
request. Although Maners, col. 5, lines 44-46 discloses that the computer system 206 issues out 
the purchase order, Maners does not disclose that computer system 206 generates the purchase 
order. Moreover, Maners does not disclose anywhere who generates the purchase order and 
most certainly does not disclose that the computer system 206 generates the purchase order. 

Even if Maners does disclose that the computer system 206 generates the purchase order 
(which Maners does not do), Maners does not disclose that the purchase order is generated based 
on a requisition received by the computer system 206 from the computer system 210, wherein 
the requisition comprises requirements relating to a purchase request received by the computer 
system 210 from the requestor. 

Therefore, Maners in view of Procedures in further view of Furphy does not disclose the 
preceding feature of claim 27. 

A second reason why claim 27 is not unpatentable over Maners in view of Procedures in 
further view of Furphy is that Maners does not disclose the feature: "said goods having a 
designation denoting that the goods are receivable which requires a positive confirmation from 
the requestor to provide authorization to pay for the goods". 
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Appellants assert that the preceding feature of claim 27 requires that the requestor 
provides positive confirmation to provide authorization to pay for the goods. However, Maners 
does not disclose who the requestor is and thus does not disclose that the requestor provides 
positive confirmation to provide authorization to pay for the goods. 

In fact, Maners discloses that the MicroEDI Server 202 provides positive confirmation to 
provide authorization to pay for the goods. See Maners, col. 6, lines 52-55 ("When an invoice is 
in "posted" status, the invoice has been processed by the MicroEDI Server 202 and determined 
valid and submitted to the company accounts payable computer system 206 for payment 
processing"). However, Maners does not disclose that the MicroEDI Server 202 is the requestor. 

Therefore, Maners in view of Procedures in further view of Furphy does not disclose the 
preceding feature of claim 27. 

A third reason why claim 27 is not unpatentable over Maners in view of Procedures in 
further view of Furphy in light of Tables 1 and 2 is that Maners does not disclose the feature: 
"said goods having a designation denoting that the goods are receivable which requires a 
positive confirmation from the requestor to provide authorization to pay for the goods said 
designation being stored in the front end server. 

Appellants assert that Maners does not disclose that a designation denoting that the goods 
require the positive confirmation are stored in the front end server (i.e., stored either in the 
computer system 206 (Table 1) or in the computer system 210 (Table 2)). In fact, Appellants 
assert that Maners does even disclose the existence of a designation denoting that the goods 
require the positive confirmation to provide authorization to pay for the goods. 

However, even if it is argued that the "posted" status for an invoice, as disclosed in 
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Mailers, col. 6, lines 52-55 is the designation denoting that the goods require the positive 
confirmation (which Appellants do not agree with), Appellants assert that Maners, col. 6, lines 
34-38 discloses that the MicroEDI Server 202 comprises an invoice history table (e.g., the table 
shown in Maners, FIG. 4) and that Maners, col. 6, lines 52-55 discloses that an invoice having 
the "posted" status is stored in the invoice history table in the MicroEDI Server 202, and not in 
the computer system 206 or in the computer system 210. 

Therefore, Maners in view of Procedures in further view of Furphy does not disclose the 
preceding feature of claim 27. 

A fourth reason why claim 27 is not unpatentable over Maners in view of Procedures in 
further view of Furphy in light of Tables 1 and 2 is that Maners does not disclose the feature: 
"said application server comprising a positive confirmation bridge; ... said positive confirmation 
bridge marking the invoice to indicate that said positive confirmation is required. 

In Table 1 and Table 2, the application server is the MicroEDI Server 202 (or application 
220), and Maners does not disclose that the MicroEDI Server 202 (or application 220) comprises 
a positive confirmation bridge that marks the invoice to indicate that said positive confirmation 
is required. Instead, the MicroEDI Server 202 marks the invoice listed in the table shown in 
Maners, FIG. 4as having "posted" status denoting that the invoice is valid and does not denote 
that the positive confirmation is required. (See Maners, col. 6, lines 52-55). 

Therefore, Maners in view of Procedures in further view of Furphy does not disclose the 
preceding feature of claim 27. 


A fifth reason why claim 27 is not unpatentable over Maners in view of Procedures in 
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further view of Furphy in light of Tables 1 and 2 is that Maners does not disclose the feature: "a 
positive confirmation from the requestor to provide authorization to pay for the goods, ... said 
front end server comprising a positive confirmation application said positive confirmation 
application providing notice to the requestor that the invoice has been received and that the 
invoice includes the required positive confirmation". 

Appellants assert that Maners does not disclose that a positive confirmation application 
in the front end server (i.e., in the computer system 206 (Table 1) or in the computer system 210 
(Table 2)) providing notice to the requestor that the invoice has been received and that the 
invoice includes the required positive confirmation of authorization to pay for the goods. 

Moreover, Maners does not even identify the requestor and thus does not disclose 
providing notice to the requestor that the invoice has been received and that the invoice includes 
the required positive confirmation of authorization to pay for the goods. 

Therefore, Maners in view of Procedures in further view of Furphy does not disclose the 
preceding feature of claim 27. 

A sixth reason why claim 27 is not unpatentable over Maners in view of Procedures in 
further view of Furphy in light of Tables 1 and 2 is that Maners does not disclose the feature: 
"said front end server receiving a response from the requestor for authorizing or rejecting 
payment for the goods". 

Appellants assert that Maners does not disclose that the front end server (i.e., the 
computer system 206 (Table 1) or the computer system 210 (Table 2)) receives a response from 
the requestor for authorizing or rejecting payment for the goods. 

In fact, Maners discloses that the MicroEDI Server 202 (and not the requestor) authorizes 
S/N: 09/819,462 30 


or rejects payment for the goods. See Maners, col. 6, lines 34-36 ("the MicroEDI Server 202 
authenticates the vendor ID number and password and determines that a user is authorized") and 
Maners, col. 6, lines 52-55 ("the invoice has been processed by the MicroEDI Server 202 and 
determined valid and submitted to the company accounts payable computer system 206 for 
payment processing"). 

Moreover, Maners does not even identify the requestor and thus does not disclose that the 
requestor authorizes or rejects payment for the goods. 

Therefore, Maners in view of Procedures in further view of Furphy does not disclose the 
preceding feature of claim 27. 

A seventh reason why claim 27 is not unpatentable over Maners in view of Procedures in 
further view of Furphy in light of Tables 1 and 2 is that Maners does not disclose the feature: 
"said positive confirmation application providing notice to the requestor that the invoice has 
been received and that the invoice includes the required positive confirmation, said notice 
directing the requestor to a location where the positive confirmation can be performed". 

As stated supra, the Examiner has not even addressed the recited feature of "said notice 
directing the requestor to a location where the positive confirmation can be performed" and has 
thus failed to establish a prima facie case of obviousness in relation to claim 27. 

In addition, Appellants have explained supra in conjunction with the fifth reason that 
Maners does not disclose that a positive confirmation application in the front end server (i.e., in 
the computer system 206 (Table 1) or in the computer system 210 (Table 2)) provides notice to 
the requestor that the invoice has been received. 

Furthermore, Appellants assert that Maners does not disclose that such notice, which 
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states that the invoice has been received and that includes the required positive corrfirmation, 
also directs the requestor to a location where the positive confirmation can be performed". 

Therefore, Maners in view of Procedures in further view of Furphy does not disclose the 
preceding feature of claim 27. 

An eighth reason why claim 27 is not unpatentable over Maners in view of Procedures in 
further view of Furphy in light of Tables 1 and 2 is that Maners does not disclose the feature: 
"after said front end server receiving the response, said front end server recording the response 
in the database". 

As stated supra, the Examiner has not even addressed the recited feature of "after said 
front end server receiving the response, said front end server recording the response in the 
database" and has thus failed to establish a prima facie case of obviousness in relation to claim 
27. 

In addition, Appellants note that Maners, col. 6, lines 52-56 recites: "When an invoice is 
in 'posted' status, the invoice has been processed by the MicroEDI Server 202 and determined 
valid and submitted to the company accounts payable computer system 206 for payment 
processing", which does not disclose recording the response (for authorizing or rejecting 
payment for the goods) in the database. 

Therefore, Maners in view of Procedures in further view of Furphy does not disclose the 
preceding feature of claim 27. 


Based on the preceding arguments, Appellants respectfully maintain that claim 27 is not 
unpatentable over Maners in view of Procedures in further view of Furphy, and that claim 27 is 
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in condition for allowance. 


Claim 28 

Since claim 28 depends from claim 27, which Appellants have argued supra to not be 
unpatentable over Maners in view of Procedures in further view of Furphy under 35 U.S.C. 
§ 103(a), Appellants maintain that claim 28 is likewise not unpatentable over Maners in view of 
Procedures in further view of Furphy under 35 U.S.C. §103(a). 

In addition with respect to claim 28, Maners in view of Procedures in further view of 
Furphy does not disclose the feature: "wherein the received response is for authorizing payment 
for the goods". 

The Examiner argues that the preceding feature of claim 28 is disclosed in Maners, col. 
5, lines 47-49 and col. 6, lines 59-60. 

In response, Appellants cite Maners, col. 5, lines 47-49 which recites: "In this case, the 
invoice information received from a vendor computer system is validated in real-time before 
acceptance for posting in the company's accounting computer system." Appellants assert that 
the preceding quote from Maners, col. 5, lines 47-49 related to invoice information and not to a 
response for authorizing payment for the goods. Therefore, Maners, col. 5, lines 47-49 does not 
disclose the preceding feature of claim 28. 

In response, Appellants cite Maners, col. 6, lines 59-60 which recites: "An invoice that 
has been assigned a "refused" status has been rejected for payment", which does not disclose 
storing anything relating to a response for authorizing payment for the goods and is therefore 
irrelevant to the preceding feature of claim 28. 

Accordingly, claim 28 is not unpatentable over Maners in view of Procedures in further 
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view of Furphy. 


Claim 30 

Since claim 30 depends from claim 27, which Appellants have argued supra to not be 
unpatentable over Maners in view of Procedures in further view of Furphy under 35 U.S.C. 
§ 103(a), Appellants maintain that claim 30 is likewise not unpatentable over Maners in view of 
Procedures in further view of Furphy under 35 U.S.C. §103(a). 

Claim 31 

Since claim 3 1 depends from claim 27, which Appellants have argued supra to not be 
unpatentable over Maners in view of Procedures in further view of Furphy under 35 U.S.C. 
§ 103(a), Appellants maintain that claim 31 is likewise not unpatentable over Maners in view of 
Procedures in further view of Furphy under 35 U.S.C. §103(a). 

In addition with respect to claim 3 1 , Maners in view of Procedures in further view of 
Furphy does not disclose the feature: "wherein the notice directs the requestor to a location 
where the positive confirmation can be performed?'' (emphasis added. 

The Examiner argues: "Maners discloses providing notice to the requestor to a location 
where positive confirmation can be performed. "And an invoice that is assigned an "operational 
hold' status is being held for validation and posting until certain information and/or authorization 
can be obtained by the Micro EDI server 202. Typically, an operational hold' status for an 
invoice requires additional information or authorization be entered into the MicroEDl Server 202 
by company personnel." Col. 6 lines 60-67; and notification of authorization agent in col. 9, also 
col. 11 claims 5,8." 
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In response, Appellants assert that the Examiner's quote and discussion of Maners, col. 6, 
lines 60-67 discloses that an operational hold' status for an invoice requires additional 
information or authorization be entered into the MicroEDl Server 202 by company personnel, 
which does not disclose that the notice directs the requestor to a location where the positive 
confirmation can be performed as claimed. 

In further response, Appellants assert that the Examiner's citation of Maners, col. 6, lines 
60-67 discloses in Maners, col. 9, lines 5-8 "to notify the authorizing agent for the company, 
such as at a computer system 224, that a particular orphan invoice requires a release 
authorization", which does not disclose that the notice directs the requestor to a location where 
the positive confirmation can be performed as claimed. 

In further response, Appellants assert that the Examiner's citation of Maners, col. 1 1, 
claim 5 recites "wherein the invoice information includes an authorizing agent and wherein the 
invoice processing server is further operable to notify the authorizing agent to determine if the 
invoice is authorized for processing", which does not disclose that the notice directs the 
requestor to a location where the positive confirmation can be performed as claimed. 

In further response, Appellants assert that the Examiner's citation of Maners, col. 11, 
claim 8 recites "sending a message to an authorizing agent requesting payment authorization to 
validate the invoice information", which does not disclose that the notice directs the requestor to 
a location where the positive confirmation can be performed as claimed. 

Accordingly, claim 3 1 is not unpatentable over Maners in view of Procedures in further 
view of Furphy. 


Claim 32 
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Since claim 32 depends from claim 27, which Appellants have argued supra to not be 
unpatentable over Maners in view of Procedures in further view of Furphy under 35 U.S.C. 
§103(a), Appellants maintain that claim 32 is likewise not unpatentable over Maners in view of 
Procedures in further view of Furphy under 35 U.S.C. §103(a). 

In addition with respect to claim 32, Maners in view of Procedures in further view of 
Furphy does not disclose the feature: "wherein the application server further comprises a 
confirmation interface to the database, wherein the confirmation interface is configured to be 
executed by the positive confirmation application, and wherein the method further comprises 
after said providing notice and before said receiving the response: providing the confirmation 
interface to the requester to enable the requestor to both enter an identifier of the invoice and 
obtain access to data comprised by the invoice". 

The Examiner argues: "Maners do not specifically disclose wherein the application 
server further comprises a confirmation interface to the database, Furphy however teaches a 
communication interface provided to both the buying and selling companies to resolve 
discrepancies between the purchase order data and the invoice data. Col. 4 lines 32-35; col. 5 
lines 20-28; col. 8 lines 33-41 response via interface." 

In response, Appellants assert that the Examiner's allegation in Furphy of a 
"communication interface provided to both the buying and selling companies to resolve 
discrepancies between the purchase order data and the invoice data" does not read on "the 
confirmation interface ... to enable the requestor to both enter an identifier of the invoice and 
obtain access to data comprised by the invoice" as claimed. 

Accordingly, claim 32 is not unpatentable over Maners in view of Procedures in further 
view of Furphy. 
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Claim 33 

Since claim 33 depends from claim 27, which Appellants have argued supra to not be 
unpatentable over Maners in view of Procedures in further view of Furphy under 35 U.S.C. 
§103(a), Appellants maintain that claim 33 is likewise not unpatentable over Maners in view of 
Procedures in further view of Furphy under 35 U.S.C. §103(a). 
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GROUND OF REJECTION 2 

Claims 22 and 29 stand rejected under 35 U.S.C. § 103(a) as allegedly being 
unpatentable over Maners, Procedures, and Furphy as applied to claim 21 above, and further in 
view of Gershenfeld, (Gershenfeld, Nancy. "Client-server: What Is It and Are We There Yet?" 
Online. Medford: Mar. 1995. Vol. 19, Iss. 2; pg. 60, 5 pages). 

Claim 22 

Since claim 22 depends from claim 1, which Appellants have argued supra to not be 
unpatentable over Maners in view of Procedures in further view of Furphy under 35 U.S.C. 
§ 103(a), Appellants maintain that claim 22 is likewise not unpatentable over Maners, 
Procedures, and Furphy, and further in view of Gershenfeld under 35 U.S.C. §103(a). 

In addition with respect to claim 22, Maners, Procedures, and Furphy, and further in view 
of Gershenfeld does not disclose the feature: "said application server notifying the back end 
server via the requisition bridge that payment for the goods has been authorized". 

The Examiner argues: "Maners discloses "When an invoice is in "posted" status, the 
invoice has been processed by the Micro EDI server 220 and determined valid and submitted to 
the company accounts payable computer system 206 for payment processing." Col. 6 lines 
52-55; Fig. 4." 

In response, Appellants note that the Examiner is alleging that the preceding quote from 
Maners, col. 6, lines 52-54 discloses the step of "notifying the back end server via the requisition 
bridge that payment for the goods has been authorized" as claimed, which Appellants do not 
agree with because according to Table 1 (see supra discussion of claim 1 for Table 1), the back 
end server in Maners is the computer system 210 which is the vendor and not the computer 
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system 206 disclosed in Maners, col. 6, lines 52-54. 

Thus, if the Examiner states that the Examiner's arguments are based on Table 2 rather 
than on Table 1 for claim 22, then the Examiner is required to use Table 2 for claim 1 since 
claim 22 depends from claim 1, and Appellants arguments supra has invalidated the rejection of 
claim 1 based on Table 2. 

Accordingly, claim 22 is not unpatentable over Maners, Procedures, and Furphy, and 
further in view of Gershenfeld. 

Claim 29 

Since claim 29 depends from claim 27, which Appellants have argued supra to not be 
unpatentable over Maners in view of Procedures in further view of Furphy under 35 U.S.C. 
§103 (a), Appellants maintain that claim 29 is likewise not unpatentable over Maners, 
Procedures, and Furphy, and further in view of Gershenfeld under 35 U.S.C. §103(a). 

In addition with respect to claim 29, Maners, Procedures, and Furphy, and further in view 
of Gershenfeld does not disclose the feature: "said application server notifying the back end 
server via the requisition bridge that payment for the goods has been authorized". 

The Examiner argues: "Maners discloses "When an invoice is in "posted" status, the 
invoice has been processed by the Micro EDI server 220 and determined valid and submitted to 
the company accounts payable computer system 206 for payment processing." Col. 6 lines 
52-55; Fig. 4." 

In response, Appellants note that the Examiner is alleging that the preceding quote from 
Maners, col. 6, lines 52-54 discloses the step of "notifying the back end server via the requisition 
bridge that payment for the goods has been authorized" as claimed, which Appellants do not 
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agree with because according to Table 1 (see supra discussion of claim 1 for Table 1), the back 
end server in Maners is the computer system 210 which is the vendor and not the computer 
system 206 disclosed in Maners, col. 6, lines 52-54. 

Thus, if the Examiner states that the Examiner's arguments are based on Table 2 rather 
than on Table 1 for claim 29, then the Examiner is required to use Table 2 for claim 27 since 
claim 29 depends from claim 27, and Appellants arguments supra has invalidated the rejection 
of claim 27 based on Table 2. 

Accordingly, claim 29 is not unpatentable over Maners, Procedures, and Furphy, and 
further in view of Gershenfeld. 
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SUMMARY 


In summary, Appellants respectfully requests reversal of the January 21, 2009 Office 
Action rejection of claims 1 and 20-33. 
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APPENDIX A - CLAIMS ON APPEAL 

1 . A computer implemented method for generating a goods receipt for approving and paying an 
invoice for commodities triggered by a three way match whereby said invoice must match terms 
and conditions of a purchase order, and goods received must match those stated in quality and 
quantity against said purchase order, said method comprising the steps of: 

receiving, by a front end server from a requestor, a purchase request for goods, said 
goods having a designation denoting that the goods are receivable which requires a positive 
confirmation from the requestor to provide authorization to pay for the goods, said designation 
being stored in the front end server, an invoice processing system comprising the front end 
server, an application server and a back end server, said back end server coupled to the front end 
server via the application server, said front end server comprising a positive confirmation 
application and a database, said application server comprising a positive confirmation bridge; 

sending, by the front end server to the back end server, a requisition comprising 
requirements relating to the received purchase request and including the designation; 
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generating, by the back end server in response to receiving the requisition sent by the 
front end server, said purchase order based on the requisition; 

said back end server transmitting or delivering the purchase order to a vendor that can 
provide the requested goods; 

after said transmitting or delivering the purchase order to the vendor, said application 
server receiving an invoice from the vendor, said invoice referencing the purchase order and 
requesting payment for the goods; 

after said application server receiving the invoice from the vendor, said positive 
confirmation bridge marking the invoice to indicate that said positive confirmation is required; 

after said positive confirmation bridge marking the invoice, said back end server 
receiving the invoice from the application server; 

responsive to said back end server receiving the invoice from the positive confirmation 
bridge, said back end server communicating transaction information pertaining to the invoice to 
the front end server; 

after said communicating transaction information, said positive confirmation application 
providing notice to the requestor that the invoice has been received and that the invoice includes 
the required positive confirmation; 

after said providing notice to the requestor, said front end server receiving a response 
from the requestor for authorizing or rejecting payment for the goods; 

if the received response is for authorizing payment, then creating an automated receipt 
transaction file including a goods receipt and entering said transaction file into an enterprise 
resource planning system for payment; and 

if the received response is for rejecting payment, then creating an e-mail notification to 
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an accounts payable system for returning said invoice to said vendor. 

20. The method of claim 1, said method further comprising: after said front end server receiving 
the response, said front end server recording the response in the database. 

21. The method of claim 1, wherein the received response is for authorizing payment for the 
goods. 

22. The method of claim 21, wherein the application server further comprises a requisition 
bridge, wherein the method further comprises: after said receiving the response, said application 
server notifying the back end server via the requisition bridge that payment for the goods has 
been authorized. 

23. The method of claim 1, wherein the received response is for rejecting payment for the 
goods. 

24. The method of claim 1 , wherein the notice directs the requestor to a location where the 
positive confirmation can be performed. 

25. The method of claim 1, wherein the application server further comprises a confirmation 
interface to the database, wherein the confirmation interface is configured to be executed by the 
positive confirmation application, and wherein the method further comprises after said providing 
notice and before said receiving the response: providing the confirmation interface to the 
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requester to enable the requestor to both enter an identifier of the invoice and obtain access to 
data comprised by the invoice. 

26. The method of claim 25, wherein said receiving the response is performed via the 
confirmation interface. 

27. A computer implemented method for processing a purchase request for goods or services, 
said method comprising: 

receiving, by a front end server from a requestor, the purchase request for goods or 
services, said goods or services having a designation denoting that the goods or services are 
receivable which requires a positive confirmation from the requestor to provide authorization to 
pay for the goods and services, said designation being stored in the front end server, an invoice 
processing system comprising the front end server, an application server and a back end server, 
said back end server coupled to the front end server via the application server, said front end 
server comprising a positive confirmation application and a database, said application server 
comprising a positive confirmation bridge; 

sending, by the front end server to the back end server, a requisition comprising 
requirements relating to the received purchase request and including the designation; 

generating, by the back end server in response to receiving the requisition sent by the 
front end server, a purchase order based on the requisition; 

said back end server transmitting or delivering the purchase order to a vendor that can 
provide the requested goods or services; 

after said transmitting or delivering the purchase order to the vendor, said application 
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server receiving an invoice from the vendor, said invoice referencing the purchase order and 
requesting payment for the goods or services; 

after said application server receiving the invoice from the vendor, said positive 
confirmation bridge marking the invoice to indicate that said positive confirmation is required; 

after said positive corifirmation bridge marking the invoice, said back end server 
receiving the invoice from the application server; 

responsive to said back end server receiving the invoice from the positive confirmation 
bridge, said back end server communicating transaction information pertaining to the invoice to 
the front end server; 

after said communicating transaction information, said positive confirmation application 
providing notice to the requestor that the invoice has been received and that the invoice includes 
the required positive confirmation, said notice directing the requestor to a location where the 
positive confirmation can be performed; 

after said providing notice to the requestor, said front end server receiving a response 
from the requestor for authorizing or rejecting payment for the goods or services; and 

after said front end server receiving the response, said front end server recording the 
response in the database. 

28. The method of claim 27, wherein the received response is for authorizing payment for the 
goods. 


29. The method of claim 28, wherein the application server further comprises a requisition 
bridge, wherein the method further comprises: after said receiving the response, said application 
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server notifying the back end server via the requisition bridge that payment for the goods has 
been authorized. 

30. The method of claim 27, wherein the received response is for rejecting payment for the 
goods. 

3 1 . The method of claim 27, wherein the notice directs the requestor to a location where the 
positive confirmation can be performed. 

32. The method of claim 27, wherein the application server further comprises a confirmation 
interface to the database, wherein the confirmation interface is configured to be executed by the 
positive confirmation application, and wherein the method further comprises after said providing 
notice and before said receiving the response: providing the confirmation interface to the 
requester to enable the requestor to both enter an identifier of the invoice and obtain access to 
data comprised by the invoice. 

33. The method of claim 32, wherein said receiving the response is performed via the 
confirmation interface. 
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